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Abstract 

An  applicative  language  based  upon  recent  ideas  by  John 
Backus  has  been  developed.  The  language  orovides  a powerful 
formalism  for  the  expression  of  complex  database  emeries. 
Though  currently  imolemented  with  an  interface  to  a CODASYL 
system,  the  language  emoloys  a sufficiently  general  data 
model  that  use  with  other  database  management  systems  is 
possible.  This  oaDer  describes  the  lanauage  throuah  a 
number  of  examoles  and  outlines  its  implementation. 
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FQL  — A Functional  Query  Languaae 


1.0  INTRODUCTION 

Formal  database  query  languages  are  extraordinarily 
varied,  ranging  from  the  alqebraically  based  relational 
languages  [3,  10]  to  those  languages  provided  with  some 
CODASYL  systems  [4]  which  give  the  user  direct  access  to  the 
data-manipulation  routines  within  the  database  management 
system.  The  Functional  Query  Languaae  described  here,  FQL, 
was  originally  desianed  and  implemented  in  an  effort  to 
provide  a powerful  and  structured  interface  to  a CODASYL 
database  management  system.  Constructing  an  interface  to 
other  database  systems  should,  however,  present  little 
difficulty  as  the  data  model  used  by  the  language  is  quite 
general:  FQL  may  in  fact  serve  as  a common  query  language 

for  communication  with  different  database  systems. 

FQL  is  an  applicative  languaqe;  and  embodies  many  of 
the  ideas  concerning  functional  programming  systems  recently 
described  by  Backus  [1].  The  only  control  structure  in  fact 
available  to  the  user  is  the  abilitiy  to  combine  functions. 
The  means  for  explicit  data  reference  (i.e.,  variables)  have 
been  purposely  omitted  from  the  language.  As  a result,  FQL 
differs  from  other  auery  languages  in  several  important 
respects . 

1.  There  is  no  notion  of  data  currency:  many  guerv 

systems  (the  relational  languages  aie  a notable 
exception)  operate  on  a " record-at-a-time"  basis 
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strongly  reminiscent  of  what  Backus  terms  the 
"von-Neumann  bottleneck". 

2.  Complex  aueries  may  be  develooed  incrementally  from 

simpler  queries:  a query  in  FQL  is  no  more  than 

another  function  over  the  database  which,  usinq  the 
mechanisms  provided  by  the  lanquaqe,  can  be 
combined  with  other  queries. 

3.  Full  computational  power  is  provided:  many  query 

languaqes  lack  the  ability  to  do  basic  arithmetic, 
let  alone  recursion  (some  relational  lanquaqe  are 
particularly  weak  in  this  respect). 

4.  The  lanquaqe  itself  is  independent  of  any  database 

system:  the  data  model  it  employs  can  be 

interfaced  with  database  systems  other  than 
CODASYL. 


It  should  be  emphasized  that  we  do  not  see  FQL  as  the 
"ideal"  end-user  query  lanquage;  nor  do  we  believe  that 
such  a language  exists.  Rather,  it  is  presented  as  a 
precise  and  powerful  formalism  for  the  expression  of 
database  queries.  Our  hope  is  that  FQL  (or  some  syntactic 
variant  of  it)  can  serve  both  as  a tool  for  those  wishing  to 
construct  complex  queries  and  as  an  intermediate  lanquaqe 
into  which  one's  "favorite"  query  lanquaae  mav  be  readily 
translated  (an  early  version  of  FQL  is  currently  in  use  as  a 
database  interface  for  a natural  language  system  [7]). 

The  main  Purpose  of  this  paper  is  to  provide  an 
informal  introduction  to  FQL.  In  the  following  section  the 
rudiments  of  the  lanauage  together  with  simple  examples  of 
their  application  are  presented.  Some  issues  of 
implementation  are  then  outlined.  The  final  section  of  the 
oaoer  is  devoted  to  a discussion  of  the  future  development 
of  FQL  includinq  its  extension  to  other  database  systems  and 


FQL  — A Functional  Ouery  Language 


Page  3 


its  mote  qenetal  cole  as  an  aoolications  language. 

2.0  THE  LANGUAGE 

2.1  A Functional  View  Of  Databases 

Since  FQL  is  a functional  language,  we  need  to  adopt  a 
functional  view  of  databases.  We  regard  a database  as  a 
collection  of  functions  over  various  data-types . Fioure  1 
shows  the  schema  of  a (very  simple)  database  containing 
entities  of  tyoe  EMPLOYEE  and  of  tyoe  DEPARTMENT. 


The  function  DEPT  in  this  example  reoresents  a mapoing 
between  these  types;  that  is,  qiven  an  EMPLOYEE,  DEPT 
returns  that  DEPARTMENT  in  which  he  works.  In  addition, 
this  database  furnishes  functions  which  maD  these  entities 
into  basic  types:  the  functions  ENAME  and  DNAME  each  return 
a CHAR(acter  string);  the  function  SAL(aiv)  yields  a 
NUM(eric)  value;  and  the  300L(ean)  function  MARRIED  serves 
as  a oredicate.  To  summarize  using  conventional  notation: 
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DEPT  s EMPLOYEE  ->  DEPARTMENT 

BNA.ME  s EMPLOYEE  ->  CHAP 

SAL  s EMPLOYEE  ->  NUM 

MARRIED  : EMPLOYEE  ->  BOOL 

DNAME  : DEPARTMENT  ->  CHAR 

Of  the  five  data-tyoes  seen  here,  CHAR,  NUM,  and  BOOL 
are  standard  in  that  they  exist  independently  of  any 
database.  On  the  other  hand,  the  types  EMPLOYEE  and 
DEPARTMENT  together  with  the  five  functions  described  above 
are  specific  to  this  database.  It  should  also  be  noted  that 
we  regard  all  of  these  tyoes  as  scalar . Information  about 
EMPLOYEES  or  DEPARTMENTS  may  only  be  obtained  throuqh  those 
database  functions  which  map  these  entities  into  "printable" 
types  (e.g.,  CHAR). 


2.2  Creating  New  Functions 

Knowing  that  the  database  defines  a set  of  functions  we 
need  mechanisms  — functional  forms  as  Backus  terms 
them  — for  combining  these  operators  to  create  new  and  more 
powerful  functions.  Of  these  mechanisms,  the  most 
fundamental  is  composition.  One  might,  for  instance,  wish 
to  define  a function  which,  given  an  employee,  returns  the 
name  of  the  department  in  which  he  works: 

DEPTNAME:  EMPLOYEE->CHAR  - DEPT. DNAME? 

This  example  shows  the  svntax  of  an  FQL  function  definition: 


DEPTNAME  is  declared  to  be  a function  from  EMPLOYEE  to 
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CHAR(actet  string)  and  defined  to  be  the  comDosition  of  the 
functions  DEPT  and  DNAME  las  denoted  by  the  ooerator  " . " ) . 
Observe  that  these  functions  ate  composed,  and  hence 
evaluated,  from  left  to  right  (reverse  Polish):  the 
DEPARTMENT  returned  by  aoclyinq  DEPT  to  an  EMPLOYEE  serves 
as  the  ooerand  for  DNAME  which,  in  turn,  produces  a value  of 
type  CHAR.  Using  reverse  Polish  foi  functional  composition 
in  fact  seems  quite  natural:  the  left  to  riqht  order  of  the 
functions  determines  a cor respondinq  path  through  the 
database  schema. 

So  far,  we  have  considered  only  those  functions  within 
the  database  which  map  scalars  into  other  scalars;  and  thus 
any  functions  one  might  define  usinq  comoosition  would  be 
scalar  as  well.  We  have  yet  to  deal  with  collections  of 
objects  such  as  the  set  of  all  EMPLOYEES  within  a particular 
DEPARTMENT.  To  do  so,  we  must  augment  our  view  of  the 
database  to  include  the  inverse  of  functions.  Returning  to 
out  samde  database  the  inverse  of  the  function  DEPT, 
written  IDEPT,  maps  a DEPARTMENT  into  a sequence  of  all 
those  EMPLOYEES  who  belong  to  the  qiven  department; 
similarly,  the  function  ! DNAME  maos  a CHAR(acter  string) 
into  a sequence  of  DEPARTMENTS1-.  We  shall  use  the  term 
stream  to  refer  to  such  a sequence  of  obiects  of  a given 
data-tyoe.  (A  stream,  following  Landin  [8]  and  Burae  [21, 


1.  Strictly  soeaking  ! DNAME  is  not  the  mathematical 
inverse  of  DNAME  as  the  inverse  of  a function  contains  no 
notion  of  sequentiality. 
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is  a "virtual''  sequence  of  obiects  whose  ohvsical 
reoresentation  should  be  of  no  concern  to  the 
programmer  — it  mav  be  a list  in  orimary  store,  a file  in 
secondary  store,  a generating  function,  or  some  combination 
of  these.)  Whether  or  not  the  inverse  of  a given  function  is 
available  deoends  uoon  the  database:  there  is  no  guarantee 
that,  because  the  function  SAL  exists,  its  inverse,  !SAL, 
will  also  be  oresent.  Database  systems  do,  though,  usually 
e.moloy  sooh ist icated  mechanisims  for  reotesentino  inverses 
of  functions  when  they  are  required.  For  examole,  1DEPT 
would  be  imolemented  through  a CODASYL  set,  while  ! DNAME 
might  be  imolemented  using  a hash  table. 


We  return  now  to  the  task  of  creating  new  functions,  in 
particular  functions  which  mao  streams  into  other  streams. 
For  this,  we  introduce  two  additional  functional  forms, 
extension  and  restriction.  The  first  of  these  allows,  sav, 
the  function  SAL  (a  maooino  from  EMPLOYEE  to  MUM)  to  be 
“extended"  into  a function,  denoted  *3AL,  which,  qiven  a 
stream  of  EMPLOYEES,  returns  a stream  of  NUMs  by  aoolyina 
tne  function  SAL  to  each  EMPLOYEE  within  the  stream.  The 
second  functional  form  allows  streams  to  be  filtered  by 
predicates  over  individual  elements:  the  function  | MARRIED 
maos  a stream  of  EMPLOYEES  into  the  sub-stream  of  EMPLOYEES 
satisfying  the  condition  that  thev  be  MARRIED.  Note  that 
while  extension  will  oreserve  the  length  of  a given  stream, 
restriction  generally  will  return  fewer  elements.  As  an 
examole,  these  ooerators  are  used  to  create  a function  which 
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letutns  a stream  of  salaries  of  all  Tattled  emoloyees  within 
a given  ieoartment: 


MARRIED-SALS : DEPARTMENTS  *NUM  * ! DEPT. | MARRIED. *SAL; 


Hete,  MARRIED-SALS  is  defined  as  a function  from  tvoe 
DEPARTMENT  into  a stream  of  NUMs  (we  use  *NUM  to  denote  the 
data-tvoe  of  a stream  of  entities  of  tvoe  MUM ) . It  is 
foiled  by  aoolyinq  the  invetse  of  DEPT,  SOEPT,  to  oroduce  a 
stream  of  EMPLOYEES;  this  stream  is  restuicted  to  that 
sub-stream  satisfying  the  predicate  MARRIED;  the  function 
SAL  is  then  aoolied  to  each  of  the  remaining  EMPLOYEES 
yielding  a stream  of  NUMs. 


A final  functional  form,  construction,  is  needed  to 
create  functions  that  returns  tuoles  of  objects;  for 
instance,  an  employee  's  name  and  salary.  In  that  case  the 
notation  [ENAME,SAL]  signifies  a mapping  from  EMPLOYEE  to  a 
pair  comprising  a CHAR  and  a MUM.  Thus  we  would  write: 


NAME-AND-SALS  : EMPLOYEES  [CHAR , MUM  ] =*  [ EMA.ME , SAL  ] ; 


The  range  of  this  function,  [CHAR , NUM ] , denotes  the 
data-tyoe  of  tuoles  of  tvoe  CHAR  and  NUM.  Tuoles,  in  fact, 
will  become  important  when  operators  such  as  addition  ate 
introduced  since,  by  desiqn,  all  FQL  functions  (primitive  or 
comoosite)  are  monadic:  the  operator  "+"  represents  a 
mapping  from  a pair  of  MU Ms  into  a MUM;  e.g., 
+ : [NUM, NUM]  ->  NUM. 
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2.3  Queries 


A auei v is  a soecial 
some  "or  intable"  object 
recursively  defined  as 
tuole  of  orintables,  ot 
might  wish  to  know  "the 
mat  tied  emolovees."  To 
access  to  the  stream  of 
Again,  out  functional  view 
this  time  to  include  a set 
database  these  include: 


kind  of  function  whose 
(The  type  of  a printable 
either  that  of  a standard 
a stream  of  such.)  As  an  e 
department  names  and  salat 
realize  this  query,  howeve 
all  employees  within  the 
of  the  database  must  be 
constant"  functions 


of 


range  is 
object  is 
scalar  , a 
xamole,  we 
ies  of  all 
i , we  need 
database . 
extended  , 
. In  our 


! EMPLOYEE  : ->  ‘EMPLOYEE 
'.DEPARTMENT  : ->  ‘DEPARTMENT 

(The  absence  of  a data  type  to  the  left  of  the 
indicates  a constant  function.)  The  functions  (EMPLOYEE  and 
(DEPARTMENT  resoectively  return  streams  of  all  values  of 
tvoe  EMPLOYEE  and  DEPARTMENT  currently  in  the  database.  Of 
course,  these  functions  are  not  trulv  constants  in  that  they 
are  database  deoendent  and  that  their  values  can,  and  often 
do,  change  over  time.  Returning,  then,  to  our  Query  that 
produces  the  department  name  and  salary  of  each  married 
employee : 

Ql:  ->*  f CHAR  ,NUMl  = ! EMPLOYES . | MARRIED.  ‘ (DE PT. DNAME , S.'.L)  ; 

For  convenience,  we  will  assume  that  the  database  is  current 
and  thus  01,  like  the  function  (EMPLOYEE,  is  a "constant" 
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whose  domain  will  remain  unspecified.  Also  observe  that  the 
function  being  extended  by  the  in  this  examole  is  itself 
the  result  of  aoDlvinq  the  construction  ooerator  to  a oair 
of  functions,  one  of  which  is  the  composition  of  yet  two 
other  functions. 


To  recaoitulate , we  have  viewed  a database  as  a 
collection  of  functions  over  various  data-tyoes  and  have 
oresented  four  functionals  — comoosition,  extension, 
restriction,  construction  — for  combining  these  functions 
into  new  functions;  and  ultimately  into  aueries.  We  have 
also  introduced  two  modes  for  structuring  tvoes  — streams 
{,**>)  and  tuples  ([<*,p...])  — where  Greek  letters  denote 
arbitrary  data-types.  The  tyoes  of  the  functions  FQL's 
functionals  produce  are  summarized  in  the  followina  where 
lower-case  letters  signify  functions. 


Composition.  If  f and  g are  such  that  f:<*->£  and 
g:  P ->y  then  f.a:  V ->y. 

Extension.  If  f;o<->£  then  *f  operates  uoon  a 
stream  of  these  tyoes;  i.e.,  *f:  *<*->*£. 

Restriction.  If  o is  a oredicate  over  (i.e., 

p:°<->bool)  then  Ip;  *e<->*o(. 

Construction.  If  fd.:»<->^,  f a : a<  — > 3a_ . . - 

f„  ; o<  ->(3^  then  [f4  ,fx  . . . f*  ] : <X  ->  ( 1 . 


2.4  Standard  Functions 


The  class  of  aueries  one  can  formulate  usina  onlv  the 
functions  given  by  the  database  is  rather  limited.  Our 


/- 
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language  therefore  contains  an  ait  ay  of  standard  functions 
including  the  familial  arithmetic,  relational,  and  boolean 
operators,  a set  of  constructors  and  selectors  for 
structured  data-tyoes,  and  a number  of  "stream-reducing" 
functions  which  map  streams  into  scalars.  To  ooint  out  the 
use  of  several  of  these  functions  (a  comprehensive  listim 
may  be  found  in  an  apoendix)  consider  a ouery  which  returns 
"the  names  of  those  emolovees  who  earn  above  the  averaae 
salary  for  their  deoartment.  First,  though,  let  us  define  a 
function  AVRG  which  computes  the  mean  of  stream  of  numbers: 


AVRG : *NUM->NUM  * [/+,LSN]./; 


Here,  the  function  "/+”  (borrowinq  from  APL)  sums  the 
elements  of  the  qiven  stream  while  "LEN"  returns  its  length; 
this  pair  of  NUM(bers)  then  serves  as  the  operand  for  the 
division  ("/")  function.  Next,  let  us  define  a Predicate 
over  EMPLOYEES: 


EARNSMORE:  EMPL0YEE->900L  » 

[SAL, DEPT. ! DEPT. *SAL. AVRG] .GT; 

EARNSMORE  returns  the  value  "true"  if  the  qiven  EMPLOYEE 
earns  more  than  the  average  salary  amonq  his  co-woikeis  and 
"false"  otherwise.  The  suo-exoression  "DEPT. ! DEPT"  returns 
the  co-workers  per  se ; *SAL  retrieves  their  respective 
wages,  and  AVRG  computes  the  mean;  this  value  is  then 
compared  to  the  original  EMPLOYEE'S  salary  using  the 
relational  operator  "GT."  And  finally,  the  ouerv: 
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02:  ->*CHAR  « ! EMPLOYEE.  | EAPNSMORE. *ENAME ; 

As  a further  demonstt ation  of  the  language  we  now  turn 
to  a .Tore  complex  cruery:  "the  names  of  those  deoar tments 
and  all  of  theii  employees  in  which  the  average  salary  is 
below  $20,000  and  some  of  the  emolovees  are  not  married." 
First,  the  query  itself: 

<■ .» 

Q3:  ->*  (CHAR,*CHAR]  « 

! DE  PARTME'IT  . I ( [Pl,P2]  .AND)  .*  [ DNAME  , ! DEPT. *ENAME ) ; 

The  auery  is  formed  throuah  restrictina  the  stream  of  all 
DEPARTMENTS  by  the  conjunction  of  predicates  Pi  and  P2  as 
specified  below  (note  the  use  of  parentheses  to  enforce  the 
scope  of  the  restriction  operator);  for  each  DEPARTMENT  in 
this  sub-stream  a pair  consisting  of  its  name  and  a stream 
* of  its  EMPLOYEE'S  names  is  then  constructed.  The  predicates 

PI  and  P2  are  defined  as  follows: 

PI:  DEPARTMENTS300L  = [! DEPT . *SAL.AVRG ,# 20000 ]. LT ; 

» 

?2:  DEPARTMENTS  BOOL  =*  'DEPT.*  (MARRIED. NOT)  . /OP.; 

The  first  predicate  compares  the  average  salary  earned  in  a 
given  DEPARTMENT  with  the  value  20,000  (more  precisely,  with 
the  value  of  the  constant  function  20000).  The  second 
predicate  tests  for  the  oresence  of  some  EMPLOYEE  who  is  not 
married:  the  exoression  * (MARRIED. NOT)  yields  a stream  of 

BOOL(eans)  while  the  function  "/OR"  returns  the  value  "true" 
if  some  member  of  this  stream  is  "true." 
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2.5  A dil 1-of-Mater ials  Processor 

As  a final  exanrole,  we  will  attack  the  infamous 
bill-of-mater ials  oroblem  which,  to  our  knowledge,  eludes 
solution  (or  at  least  an  elegant  one)  within  most  database 
query  systems.  The  difficulty  here  lies  with  the  fact  that 
the  schema  required  is  inherently  recursive:  oarts  contain 
sub-oar ts  which  themselves  are  oarts;  these,  in  turn,  are 

built-uo  out  of  other  parts;  and  so  on.  The  soecific  task 

» \ 

we  shall  address  is  that  of  finding  the  total  cost  of  a 
given  part,  if  we  associate  with  each  oart  a "cost"  meaning 
either  the  purchase  orice  (in  which  case  it  has  no  sub-oarts 
of  interest  to  us)  or  else  the  expense  of  assembly,  then  the 
total  cost  of  a part  is  its  own  "cost"  added  to  the  total 
cost  of  all  of  its  sub-parts.  To  complicate  matters 
somewhat  we  will  assume  the  components  of  parts  are  used  in 
differing  quantities:  an  engine  may  require  four  piston 
assemblies  and  two  carburetors.  Fiaure  2 depicts  a possible 
schema  for  such  a database: 


Fiaure  2 
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The  relation  between  a oart  and  its  sub-oarts  is 
reoresented  by  the  USAGE  tyoe.  For  example,  if  an  enoine 
reouires  two  carburetors,  a USAGE  entity  will  be  defined 
whose  PT  is  an  enqine,  whose  COMP  is  a carburetor,  and  whose 
QTY  is  2.  The  expression  !PT.*COMP  therefore  maos  a aiven 
PART  into  a stream  of  its  immediate  COMP (onents ) ; 
conversely,  !COMP.*PT  returns  a stream  of  PARTS  in  which  a 
qiven  PART  is  an  immediate  constituent.  We  may  now  define 
the  function  TC  which  computes  a part's  total  cost: 

TC:  PART->NUM  = [COST ,! PT. *( [QTY, COMP. TC ]. x )./+].+ ; 

For  a qiven  PART,  the  total-cost  (TC)  of  each  of  its 
sub-parts  is  multiplied  by  the  required  quantity  and  then 
summed  together,  after  which  this  total  is  added  to  the  COST 
of  the  otiqinal. 

What  is  remarkable  about  this  oarticular  function  is 
that  its  definition,  despite  recursion,  includes  no  exolicit 
basis  for  termination!  (FQL  queries  do  not  usually  reauire 
the  IF-THEN-ELSE  construct  normally  associated  with 
termination  in  recursive  functions.)  Yet,  comoutation  will 
halt  since  the  database  is  finite.  This  can  be  seen  by 
examininq  the  simolest  case:  qiven  an  atomic  _ part  (one  with 
no  sub-parts),  aoolication  of  the  function  ! PT  would  yield 
the  emoty  stream;  aoolyinq  the  oarenthesized  exoression  to 
each  element  of  this  stream  oroduces,  of  course,  another 
emoty  stream;  the  sum  of  the  empty  stream  of  NUMs  is,  by 
definition,  0 (the  identity  for  addition)  which  is  then 
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added  to  the  COST  of  the  oriqinal  oart.  And  assumino  the 
components  of  all  parts  ate  ultimately  atomic  the  function 
TC  will  converqe.  Incot potation  of  the  function  into  an 
appropriate  ouery  is  left  to  the  leader  's  imagination. 

Finally,  we  should  mention  that  FQL  does  include  a set 
of  basic  stream-manioulatinq  oiimitives  based  uoon  the 
1 ist-processinq  functions,  CONS,  CAR,  CDR , etc.  of  LISP. 
(These  are  described  in  an  appendix.)  It  is  inteiestinq  to 
note  that  for  most  database  queries  explicit  use  of  these 
operators  is  not  required:  they  are  implicit  in  extension 
and  restriction.  Constructinq  a bill-of-mater ials  processor 
which  lists  all  the  sub-parts  of  a qiven  part  would, 
however,  call  for  a direct  use  of  CONS.  (Aqain,  this  is 
left  as  an  exercise  for  the  reader.) 

3.0  IMPLEMENTATION 

In  its  current  form,  FQL  is  implemented  in  PASCAL  as  an 
interface  to  SEED  [6],  a CODASYL-based  database  manaqement 
system  written  in  FORTRAN,  and  is  runninq  on  The  Wharton 
School's  DEC-10.  Little  difficulty  is  foreseen  in 
transferring  FQL  to  other  machines  or,  if  necessary, 
re-writing  its  source  code  in  some  other  pioatammina 
language.  Interfacing  to  other  CODASYL  systems  may  teauire 
some  additional  code:  unless  routines  are  provided  for 
run-time  inter rooation  of  the  database  schema,  as  they  ate 
in  SEED,  a ore-processor  would  be  necessary  to  translate 
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from  the  CODASYL  data-def inition  lannuaae  (DDL)  into  a 
separate  representation  of  the  schema  used  by  FQL. 

The  maooina  between  a CODASYL  schema  and  the  functional 
model  Presented  above  Proves  quite  stiaiaht forwai da . 
Rouqhly  soeakina,  sets  and  items  correspond  to  functions 
while  the  records  become  types.  The  "functional"  database 
deoicted  earlier  in  Fiqute  1 would,  for  instance,  derive 
from  a schema  in  which  DEPARTMENT  and  EMPLOYEE  were  records, 
DNAME  and  EMAME  were  resoectively  items  within  these  records 
of  tyoe  CHAR,  and  DEPT  were  a set  owned  by  DEPARTMENT  and 
copulated  by  EMPLOYEES.  Note,  thouqh,  that  the  set  DEPT 
actually  corresponds  to  the  inverse  function  !DEPT;  the 
function  DEPT  itself  takes  a member-record  into  its  owner. 
It  should  also  be  mentioned  that  inverse  functions  such  as 
! DNAME  are  only  available  when  the  cor tesoond inq  item  (DNAME 
in  this  case)  serves  as  a CALC  key. 

Strictly  SDeakinq,  CODASYL  sets  cortesoond  to  functions 
only  when  meirbershio  is  both  MANDATORY  and  AUTOMATIC.  In 
other  cases  we  may  only  assume  that  a set  defines  a partial 
function.  In  order  to  cooe  with  partial  functions,  a 
standard  object,  UNDEF,  has  been  introduced  as  a member  of 


2.  Some  CODASYL  constructs  cannot  be  represented  in  FCL's 
data  model  at  present.  These  include  arrays  toaether  with 
sets  in  which  more  than  one  record  tvoe  mav  be  owned.  There 
appear  to  be  no  fundamental  difficulties  in  extendino  FOL  to 
cooe  with  these. 
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evei  v tvne ; and  a standard  medicate,  DEFINED,  is  available 
to  test  whether  or  not  an  obiect  is  defined.  Partial 
functions  can  then  be  reoresented  bv  (total)  functions  which 
may,  at  times,  return  UNDEF. 

One  of  the  more  interesting  facets  of  the 
imolementation  of  FQL  is  the  manner  in  which  streams  are 
handled  internally.  The  problem  here  is  to  suooort  the 
user's  illusion  of  constructino  and  traversino  (oossiblv 
very  long)  lists  of  data  without  monopolizing  large  amounts 
of  otimary  store.  To  some  extent  out  solution  follows  from 
the  work  of  Friedman  and  Wise  (5)  though  there  are 
significant  differences.  To  consider  an  examole,  the 
"constant"  function  (EMPLOYEE  does  not  literally  return  a 
list  of  all  EMPLOYEES  currently  in  the  database  (to  do  so 
would  not  only  be  impractical  but  in  certain  cases 
imoossible).  Rather,  this  function  generates  a stream 
reoresented  by  an  ordered-pair  comorising  its  head , the 
first  EMPLOYEE  in  sequence,  and  its  tail,  another  function 
which,  when  apolied,  produces  a stream  of  the  remainino 
EMPLOYEES  (i.e.,  it  oroduces  another  order ed-oair ) . Amono 
the  advantages  of  this  scheme  is  that  the  amount  of  orimaty 
store  reauired  to  orocess  a sequence  of  indeterminate  length 


remains  constant 
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4.0  DISCUSSION 

In  this  section  we  shall  brieflv  discuss  extensions  to 
FQL  and  further  related  research  areas.  The  oresent  syntax 
of  FQL  makes  it  somewhat  unaainlv  as  an  end-user  ouerv 
language.  There  are  a number  of  chanaes  that  could  be  made 
to  alleviate  this  situation.  At  the  cost  of  some  run-time 
checking,  the  tyoe  declarations  on  the  left  hand  side  of 
function  definitions  could  be  eliminated.  Also,  infix 
representation  of  the  dyadic  arithmetic  and  relational 
operators  may  be  found  more  convenient.  It  is  also  oossible 
to  have  the  functional  automatically  insetted:  much  as 
APL  generalizes  its  standard  functions  over  arrays,  most 
functions  in  FQL  have  an  obvious  extension  over  streams. 
Usinq  this  simplified  syntax,  the  bil 1-of-matet ia Is  query 
described  above  reduces  to: 


TC  ■ COST  + ! PT. (QTY  x COMP.TC) .+/ 


which  is  a somewhat  more  readable  version  of  the  function. 


We  have  suqaested  that  the  functional  schema  used  bv 
FQL  is  general  enough  to  allow  reoresentation  of  other 
database  systems.  One  of  the  obvious  extensions  to  FQL  is 
an  interface  to  a relational  system.  Briefly,  each  relation 
defines  a data-tyoe  and  a set  of  functions,  one  for  each 
subset  of  its  domains.  Thus,  usino  conventional  relational 
database  notation,  if 
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E M P : (ENAME,  OEPT*,  SAL) 

describes  a relation  then,  in  the  functional  description, 
there  is  a data  tvoe  Emp  toaether  with  functions  such  as: 

5MP<ENAME,  SAL>:  EMP  ->(CHA9,NrJM) 

EM  POE  PT#  > : EMP->MUM 

etc. 

Generally,  qiven  a relation  R,  and  a subset  dj,da...d*  of 
its  domains,  theie  is  a function  denoted  by  R<dA  ,dA  . . .d(t> 
which  mans  into  the  data-tyoe  [ti,t1...t^l  where  fc  is  the 
data  tvoe  of  dj,  (l<i<k).  First  normal  form  auaiantees  that 
such  data  types  ate  alwavs  printable.  It  is  an  easy  matter 
to  imolement  these  functions  and  their  inveises  usinq  the 
operators  of  t'ne  telational  calculus.  It  may,  however,  be 
possible  to  translate  FOL  aueiies  mote  directly  into  a 
relational  aueiy  languaae,  thouah  the  Droblem  of  Dioducinq 
efficient  relational  oueries  from  an  FOL  definition  reauires 
further  work. 

It  is  interestinp  to  note  that  a relational  database 
with  added  semantics  (the  Smiths'  aoqreqation  model  [91  is  a 
pood  examole)  often  pives  rise  to  a much  simoler  functional 
reoresentation.  Direct  functions  between  relations  (the 
"natural"  joins)  are  available  and  schemata  not  unlike  those 


used  in  this  oaoer  may  be  directly  inferred  fro-*  the 
semantics . 
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'•>e  would  also  like  to  extend  FOL  to  be  a -note  general 
database  aoolications  lanauaae.  The  problem  here,  as  in  all 
aoolicative  lanquaaes,  is  that  of  uodate.  It  should  be 
oossible  to  add  the  ability  to  uodate  functions;  and  if 
this  were  done,  it  would  give  the  user  the  ability  to  define 
high  level  transactions  in  a structured  fashion.  This  may 
well  be  of  advantage  when  workinq  in  a shared  environment 
where  many  uodate  anomalies  are  caused  by  the  user  having 
exolicit  control  over  data  currency.  Other  additions  we 
would  like  to  see  to  FQL  include  functions  which  describe 
the  tvoe  of  a database  entity  and  what  functions  ate 
available.  This  would  allow  Queries  to  interrogate  the 
structure  of  the  functional  schema  and  greatly  enhance  FQL’s 
use  as  a gener al-puroose  aoolications  language. 


. 
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Aooendix  1 — FQL  Svntax 


3elow  is  aiven  the  syntax  for  a function  defintion,  a 
data-tvoe,  a functional  exDression,  and  a function  itself. 
Optional  comoonents  ate  denoted  by  I4, " while 

" { M . . . ” " signifies  a set  of  elements  may  occur  an 

arbitrary  number  of  times. 


<def>  ::=  <name>  : { <tvne>  }4 -><tyoe>*<fexpr  > ; 

<tvoe>  ::=  NTJM 
: : » CHAR 
: : = 300L 
: : * *<tyDe> 

[ <tvoe>  { , <type>  ;•*  ] 

<fexor>  <function>  ( , <f  unction>  }”*“ 

<function>  <name> 

: : * *<  f unction> 

|<function> 

[<fexor  > { , <fexor  > I-*"] 

(<fexor>) 


t 
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Appendix  2 — Standard  Functions 


The  standard  functions  supported  bv  F^L  ate  arouoed  hete  bv 
category.  Where  aoorooriate,  additional  exolanation  is 
ocovided . 

Arithmetic  functions 

The  functions  +,  x,  / , and  MOD  all  mao  from  [NUM , MUM ] 
into  NUM.  The  functions  /+  and  /x  oerform  addition-  and 
times-reduction  on  streams  of  NUMs;  i.e.,  thev  mao  *NUM 
into  MUM.  Given  an  emotv  stream  these  functions  return 
their  resoective  identities,  0 and  1. 

Relational  and  Boolean  Functions 

The  operators  EQ,  ME,  GT,  LT,  GE,  and  LE  mao  from  either 
[ MUtM , MUM  ] or  from  [ CH  AR  , CHAR  ] into  BOOL.  The  functions 
AMD  and  OR  return  a BOOL  given  (300L,300L1;  the 
comolement  NOT  takes  a BOOL  into  another  BOOL.  The  two 
reduction  onerators,  /OR  and  /AMD,  reoresent  mannings  from 
"BOOL  to  BOOL  and,  aiven  empty  streams,  return  the  values 
"true"  and  "false”  resoectively . 

Constant  Functions 

The  notation  *<numbet>  represents  a mapoinq  - >MUM  whose 
value  is  the  <number>;  the  notation  1 <char acter-str inq> * 
similarly  denotes  the  manning  ->CHAR.  The  function  NIL  is 
a constant  signifying  the  emotv  stream  of  anv  tyoe;  i.e., 

->*•<. 

Basic  Stteam-manioulating  Functions 

Given  a non-emoty  stream,  the  operation  HD  returns  its 
first  element  (*<->cA)  while  the  operation  TL  returns  a 
stream  of  the  remaining  elements  (*<<->*b<).  The  function 
CONS  takes  an  element  of  some  type  and  a (oossiblv  emotv) 
stream  whose  elements  aie  of  that  same  tyoe  and  returns  a 
new  stream  in  which  the  individual  element  is  its  "head" 
while  the  oriqinal  stream  becomes  its  "tail";  i.e., 
CONS  ; [<*,*<*]->*«. 

Other  Stream-man iDulatina  Functions 

The  function  LEM  computes  the  length  of  a aiven  stream  and 
is  thus  a maooinq  from  "<*  into  NUM.  CONC  maos  a pair  of 
streams  (whose  elements  are  of  the  same  tvoe)  into 
a sinqle  stream  *o /CONC  produces  a simle  stream  by 
"flattening"  an  arbitrary  stream  of  streams  ***.  The 
ODerator  DISTRI3  takes  a tuole  of  the  form  and 
returns  a stream  of  tuples  with  the  value  of  tvoe  £ 
"distributed"  over  the  stream  of°A’s. 
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